Re: Not able to detect current open out-link module
Tony_Goodman - Fri Dec 03 03:58:35 EST 2010
Generally, when you open a module, it becomes the "current Module", but modules at the other end of outgoing linsk are opened automatically by DOORS, so following links and opening them may not necessarily update the "current Module".
Beware of relying on the current Module being set. You should set it explicitly as follows:
// get a handle on the module
m = read("/project name/module name", true)
// force current Module setting (there two under scores in ModuleRef__)
(current ModuleRef__) = m
Tony
|
Re: Not able to detect current open out-link module
llandale - Fri Dec 03 14:16:33 EST 2010
Welcome back Tony.
As for 'current' module: This notion is useful for scripts that must have a module for their context; that is the script runs on a module. All such scripts should have something like this at the top:
Module g_modOriginal = current()
if (null g_modOriginal or
type(g_modOrginal != "Formal") {errorBox("Run from open formal module"); halt}
// some other possibilities
if (!isEdit(g_modOriginal) or
!isShare(g_modOriginal)) {errorBox("run from Share/Edit module"); halt}
This way you always have a handle on the original module when you need it, which you will when you open other modules. If you figure to use commands that require the 'current' module, you can issue: current = g_modOriginal.
When you open other modules, the 'current' module can and does change. I don't know the exact rules but I see the rules vary from DOORS version to version. The main rule, which I believe is about 90% accurate, is that the 'current' module changes when you actually open another module, but it does not change if that other module is already open. BUT WAIT! it does if the module was invisible but is now visible. BUT WAIT! it does not if that module was already the the target of an open link module. BUT WAIT! it does if you loaded the link set. BUT WAIT! It does if you close the current current module, and then re-open some already open module. BUT WAIT! It doesn't change if you close that module and then immediately re-open it, before the background client-to-server chatter has had a chance to update your client with the fact that its closed. BUT WAIT! I've made up most of these 'but waits', or maybe I'm fibbing about that. Can you tell the difference? BUT WAIT ...
Attempting to find all the rules for when the 'current' module changes is hopeless, as is trying to code to such rules. Been there, done that, wasted a good week of work, never figured it out EXACTLY.
Forget relying on "mod = current" to get what you want inside some code, other than at the top as explained above. Instead, keep track of your various 'Module' handles and use them explicitely; current = modThatIJustIponed. Understand you can always get the 'Module' handle by re-issueing a 'read' command on a full name that's already open; and in some other ways.
===As for this problem====, it seems as though you are recursively opening modules at the other end of outgoing links, will accumulate several such modules, then figure out which one is the 'key' you care about, and then you need to deal with that module. Well, open your modules and keep track of their names; when you figure out which one you care about then re-open that one to get its 'Module' handle, then use that.
|